home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / applications / 2463 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.applications
  4. Subject: Re: Executive and AmiTCP..
  5. Date: Mon, 26 Feb 96 02:00:25
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960226.543380.2124@an174.du.pipex.com>
  9. References: <778.6621T1384T1708@moor.slip.uky.edu> <4gahsu$5fm@tkhut.sojourn.com> <709.6624T80T1806@moor.slip.uky.edu> <1054.6629T1036T365@iag.net>
  10. NNTP-Posting-Host: an174.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Joseph Shaughnessy (serendip@iag.net) wrote:
  14. : 
  15. : Re: Executive and AmiTCP..Walter R FrancisWally@moor.slip.uky.edu20-Feb-96
  16. : 11:20:36
  17. :  WRF> On 19-Feb-96 14:09:18, Matt Harrell articulated:
  18. : 
  19. : >>I don't get it.  I am using Executive and the demo version of AmiTCP,
  20. : >>and I haven't noticed anything nasty.  What, exactly, is the problem?
  21. : 
  22. :  WRF> It makes all of the connections crawl to a halt, so bad FTP times out an
  23. :  WRF> other connections do the same.
  24. : 
  25. :  WRF> If I run AmiTCP without Executive, it's okay..  I run Executive everythi
  26. :  WRF> crawls..  Ex running, run AmiTCP, crawls..  Quit Ex it goes back to norm
  27. : 
  28. :  WRF> Could be something in my setup, but it seems to change some priorities A
  29. :  WRF> needs, even through I have it ignoring AmiTCP..
  30.  
  31. Of course. The startnet script launches several tasks other than AmiTCP itself -
  32. inetd, INET (the INET: device driver), NETTRACE, and any other active daemons
  33. you may have running, such as httpd, fspd, smtpd etc.
  34.  
  35. (device drivers are also launched, but these start up with a priority above
  36. Executive's default catch range, and so will not normally be sheduled anyway).
  37.  
  38. Apart from NETTRACE, none of these are childtasks of the AmiTCP task, so
  39. you cannot use Executive's TASK+CHILDTASKS option to prevent them from being
  40. sheduled. You will have to add a line for each one to Executive Prefs
  41. manually. So do a ps listing, start up AmiTCP, do a ps listing again, and add
  42. any new tasks which have appeared to Executive's prefs.
  43.  
  44. Quite _why_ the AmiTCP tasks grind to a halt when you use Executive is a
  45. mystery to me, though. I've never had any such problems. The only thing I can
  46. think of is that you are running some other CPU intensive task at the same
  47. time as AmiTCP, and are allowing this task too much CPU time.
  48.  
  49. :  WRF> I'm not saying it's a problem with Executive. :)
  50. : 
  51. :  On a similar note, and possibly related, Blitzblank will do the same things
  52. : as cited above. I finally put a line to kill Blitzblank into my startnet
  53. : script for AmiTCP. Does Executive watch/monitor the same areas/registers that
  54. : Blitzblank looks at to put up a screen blanker?
  55.  
  56. No, but many of BlitzBlank's blanker modules are very CPU intensive. If you
  57. don't shedule BlitzBlank properly, it's likely to steal a lot of CPU time
  58. from other tasks. I never found a "perfect" solution to this myself, so I
  59. went back to using the simple old C= blanker, which doesn't eat _any_ CPU
  60. time.
  61.  
  62. While I was trying to get BlitzBlank to work, the two best alternatives I
  63. found were:
  64.  
  65. BlitzBlank TASK+CHILDTASKS NOSHEDULE BELOW
  66. BlitzBlank TASK+CHILDTASKS SHEDULE NICE=+20
  67.  
  68. Both of these have problems. The first will stop BlitzBlank from responding
  69. to a mouse movement / keypress if another task is using all available CPU time
  70. (e.g. if you have a 3D render running). The second will help BlitzBlank's
  71. responsiveness somewhat, but on the downside it will start consuming CPU time
  72. which might be better spent on other tasks which you may have running in the
  73. background.
  74.  
  75. Fancy screen blankers are a tricky type of program to handle, because they use
  76. a lot of CPU time, _and_ must be very responsive to user input.
  77.  
  78. The only way to fix it completely would be to add a capability to BlitzBlank
  79. to keep an eye on Executive's CPU load stats, so that it could switch to
  80. another blanking method which consumes less or no CPU time when the total
  81. CPU load reaches a preset threshold. BlitzBlank does have its own "Watch CPU"
  82. option, but it doesn't work properly when Executive is running.
  83.  
  84. -- Mat.
  85.